The Push Notifications Console now includes metrics for notifications sent in production through the Apple Push Notification service (APNs). With the console’s intuitive interface, you’ll get an aggregated view of delivery statuses and insights into various statistics for notifications, including a detailed breakdown based on push type and priority. Introduced at WWDC23, the Push Notifications Console makes it easy to send test notifications to Apple devices through APNs. Learn more.

Team-scoped keys introduce the ability to restrict your token authentication keys to either development or production environments. Topic-specific keys in addition to environment isolation allow you to associate each key with a specific Bundle ID streamlining key management. For detailed instructions on accessing these features, read our updated documentation on establishing a token-based connection to APNs.

In my VoIP app, we use StartRing and StopRing via VoIP push to my app. But recently, I found some disordered VoIP notifications, my VoIP app received the StopRing push before the StartRing push. Examples: Server log: // send StartRing startring: - Apr 9, 2026 @ 14:54:43.255 .."pushType":"voip","priority":10, ... // send StopRing stop-ring Apr 9, 2026 @ 14:54:47.645 ..."pushType":"background","priority":5,"... VoIP app log: // receive StopRing 2026-04-0909:54:48.858 CDT : INFO : [RcRtc] [0x1feeba1c0] [PushNotificationParser]call push notification handled. action: StopRing telephony session id: s-a0dd8601926c7z19d72bbf8b9z1e62ec10000 sid: 178503189447188 // receive StartRing 2026-04-0909:54:49.524 CDT : INFO : [RcRtc] [0x1feeba1c0] [PushNotificationParser]call push notification handled. action: StartRing telephony session id: s-a0dd8601926c7z19d72bbf8b9z1e62ec10000 sid: 178503189447188 Then we can see the StartRing send first, but received in the app after the StopRing. The StartRing took abunt 6s to send and the StopRing took about 1s. So I guess there is an issue in the APNs part on iOS26.4. We saw there is a peak after iOS26.4 and iOS 26.4.1 than old iOS versions. Thanks.

Code: func pushRegistry(_ registry: PKPushRegistry, didReceiveIncomingPushWith payload: PKPushPayload, for type: PKPushType, completion: @escaping () -> Void) { print("📶 收到 VoIP 推送: (payload.dictionaryPayload)") JPUSHService.handleVoipNotification(payload.dictionaryPayload) // 解析来电信息 guard let voipInfo = payload.dictionaryPayload["_j_voip"] as? [String: Any] else { completion() return } let caller = voipInfo["relationship"] as? String ?? "未知来电" apiUserId = "\(voipInfo["apiUserId"] ?? "")" let callUUID = UUID() // 关键：直接调用 reportIncomingCall // 虽然 Task 是异步的，但我们已经用 @preconcurrency 标记了类 // 并且 PushKit 的 completion 会在之后立即调用 self.reportIncomingCall(uuid: callUUID, callerName: caller) // 立即调用 PushKit completion completion() } private func reportIncomingCall(uuid: UUID, callerName: String) { print("========来电了============="); currentCallUUID = uuid isCallNotAnswered = true let handle = Handle( type: .generic, value: callerName, displayName: callerName ) var update = Conversation.Update( localMember: handle, members: [handle], activeRemoteMembers: [handle] ) // 👇 关键：设置通话能力为支持视频和播放铃声 update.capabilities = [.video, .playingTones] // ✅ 修复数据竞争警告 Task { do { try await conversationManager.reportNewIncomingConversation(uuid: uuid, update: update) print("✅ LiveCommunicationKit 来电上报成功") } catch { print("❌ 来电上报失败: \(error.localizedDescription)") } } } When the app is in the background and VoIP messages arrive, the program crashes. The error message is:*** Assertion failure in -[PKPushRegistry _terminateAppIfThereAreUnhandledVoIPPushes], PKPushRegistry.m:349 *** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'Killing app because it never posted an incoming call to the system after receiving a PushKit VoIP push.' *** First throw call stack: (0x18df82044 0x18b419abc 0x18d27d6d0 0x21cff5494 0x107486064 0x10747d19c 0x21cff46fc 0x10746c584 0x107486064 0x1074a6f98 0x10747c548 0x10747c484 0x18ded4b74 0x18de782c4 0x18de79a0c 0x1dad01454 0x1908991a4 0x190864a28 0x10435fa1c 0x1b4965f08) libc++abi: terminating due to uncaught exception of type NSException Debug session ended with code 9: Terminated due to signal 9

Hello! I’m building a VoIP app for iPhone and Apple Watch using PushKit and CallKit. I’m trying to understand the recommended watchOS architecture for this kind of setup. What we would like is for the watch to behave as an endpoint for incoming calls, so that when a call comes in the user can answer on either the iPhone or the watch. My understanding is that VoIP notifications are not supported on watchOS, so for incoming calls what we ended up having to do was send the watch a regular APNs alert notification and only start the actual call setup after the user interacts with it. This isn’t ideal, and the notification often appears a few seconds late. What we would like to be able to do is present the incoming call on the watch more like how FaceTime calls appear on Apple Watch. So I wanted to ask whether this is the intended pattern for a companion watchOS VoIP app. Is using a regular APNs alert notification the correct way to surface an incoming call on the watch, or is there a better supported approach? Thanks!

Hi Apple Team, We are facing an issue with Live Activities where the UI intermittently fails to render and shows a loader or blank state. After extensive debugging, we’ve identified that the failure happens during the rendering phase inside the system process (WidgetKit / liveactivitiesd), but there are no actionable signals exposed to the app. Problem: Live Activity launches successfully After a few updates or under certain UI conditions, it: stops rendering shows a loader / blank UI sometimes disappears No crash logs are generated No MetricKit diagnostics available for the extension Console logs show: Invalid frame dimension (negative or non-finite) Archive was nil. LiveActivity will be empty Sometimes because of memory pressure too The extension process appears to terminate silently Challenge Currently, there is no way to detect from the app side that: the Live Activity has failed to render the extension process has crashed/terminated the UI is no longer being updated Questions Is there any callback, delegate, or lifecycle hook that notifies when: a Live Activity rendering fails the extension process crashes or is terminated by the system? Is there any recommended way to detect a “broken” Live Activity state (e.g., stuck loader / non-updating UI)? Are there any diagnostic APIs or logs we can rely on in production to identify such failures? Is this considered expected behavior under certain system constraints (e.g., memory/rendering limits), and if so, are there guidelines to proactively detect or mitigate it? Goal We want to: proactively detect Live Activity failure log it for monitoring optionally fallback or recover gracefully Additional context: We fixed all the issues and the live activity is pretty stable. But asking for methods to track & fix such cases.

I'm working on an app, and currently, 2 things dont work: account creation and notifications. I want to find the root of why these errors are occurring, and I want to know if these errors are coming from Firebase, certain settings in Xcode not being checked, or my actual written code not being typed correctly. I've tried to run my issue through ChatGPT many times to pretty much no success, so any help on what to do so I can clear certain areas and make sure the bugs aren't from certain spots, and help me narrow down the issue would be great. Otherwise, if there are other guides or threads I can be linked to, and help me fully break down the issue, that would be great. Thank you for your time reading, and I hope I can get some advice.

Hi everyone, I'm running an Apple MDM service and encountering an issue where a number of devices stop receiving MDM push commands within 10 days of profile installation, even though everything appears to be set up correctly. Environment: MDM profile is installed and verified (status: OK, result: SUCCESS) Devices are cellular-enabled with no connectivity issues APNs certificate is valid (thousands of other devices are communicating normally) The command being sent to devices is DeviceInformationCommand No "NotNow" response or any check-in received from the affected devices for over a week Issue: We send DeviceInformationCommand to devices to retrieve device information and update the last communication timestamp. However, a subset of devices simply stop responding to this command within 10 days of profile installation. The last communication date is not being updated, and no response — not even a "NotNow" — is coming back from these devices. Since other devices on the same MDM setup are working fine, I've ruled out APNs certificate expiration and general server-side issues. Questions: Are there any known management points or configuration settings that could cause a device to silently stop receiving DeviceInformationCommand shortly after enrollment? What diagnostic steps would you recommend to identify the root cause on the device or server side? Are there any known bugs or reported issues related to this behavior in recent iOS versions? Is there any way to recover the MDM communication without requiring the user to re-enroll? Any insights or suggestions would be greatly appreciated. Thank you!

I am getting InvalidProviderToken for every APNs key I create under my team. This has persisted for over a week across 3 different fresh keys. Setup: Team ID: QJLCAXKWMB Bundle ID: com.trackntakeit.app All keys: Team Scoped, All Topics, Sandbox & Production JWT: ES256, correct kid and iss fields Tested directly from Mac via curl with fresh tokens The key file is a valid EC 256-bit private key. JWT is correctly formed. Both production and sandbox endpoints return InvalidProviderToken. Case number with Apple Developer Support: 102857626802 Has anyone seen all APNs keys for an entire team being rejected? Could there be an account-level block on APNs?

Hi everyone, I have a SwiftUI app using CKQuerySubscription on the public database for social notifications (friend requests, recommendations, etc.). Push notifications work perfectly in the Development environment but never fire in Production (TestFlight). Setup: iOS 26.4, Xcode 26, Swift 6 Container: public database, CKQuerySubscription with .firesOnRecordCreation 5 subscriptions verified via CKDatabase.allSubscriptions() registerForRemoteNotifications() called unconditionally on every launch Valid APNS device token received in didRegisterForRemoteNotificationsWithDeviceToken Push Notifications + Background Modes (Remote notifications) capabilities enabled What works: All 5 subscriptions create successfully in Production Records are saved and queryable (in-app CloudKit fetches return them immediately) APNS production push works — tested via Xcode Push Notifications Console with the same device token, notification appeared instantly Everything works perfectly in the Development environment (subscriptions fire, push arrives) What doesn't work: When a record is created that matches a subscription predicate, no APNS push is ever delivered in Production Tested with records created from the app (device to device) and from CloudKit Dashboard — neither triggers push Tried: fresh subscription IDs, minimal NotificationInfo (just alertBody), stripped shouldSendContentAvailable, created an APNs key, toggled Push capability in Xcode, re-deployed schema from dev to prod Additional finding: One of my record types (CompletionNotification) was returning BAD_REQUEST when creating a subscription in Production, despite working in Development. Re-deploying the development schema to production (which reported "no changes") fixed the subscription creation. This suggests the production environment had inconsistent subscription state for that record type, possibly from the type being auto-created by a record save before formal schema deployment. I suspect a similar issue may be affecting the subscription-to-APNS pipeline for all my record types — the subscriptions exist and predicates match, but the production environment isn't wiring them to APNS delivery. Subscription creation code (simplified): let subscription = CKQuerySubscription( recordType: "FriendRequest", predicate: NSPredicate(format: "receiverID == %@ AND status == %@", userID, "pending"), subscriptionID: "fr-sub-v3", options: [.firesOnRecordCreation] ) let info = CKSubscription.NotificationInfo() info.titleLocalizationKey = "Friend Request" info.alertLocalizationKey = "FRIEND_REQUEST_BODY" info.alertLocalizationArgs = ["senderUsername"] info.soundName = "default" info.shouldBadge = true info.desiredKeys = ["senderUsername", "senderID"] info.category = "FRIEND_REQUEST" subscription.notificationInfo = info try await database.save(subscription) Has anyone encountered this? Is there a way to "reset" the subscription-to-APNS pipeline for a production container? I'd really appreciate any guidance on how to resolve and get my push notifications back to normal. Many thanks, Dimitar - LaterRex

We have an iPhone app with a companion watchOS app for factory alert monitoring. What we want to achieve is: each server event is an independent event, not just a latest-state update events should not be dropped in some scenarios, new events may arrive as frequently as once per minute the watch app state/UI should reflect the event almost in real time our target is roughly within 5 seconds the watch app is expected to be opened by the user when they want to confirm details, but we want the data to already be there even if the watch app was previously in the background notification mirroring is already sufficient for immediate user awareness; the question is about reliable background data/state delivery to the watch app Our current architecture is: The server sends APNs pushes to the iPhone app. We use both: alert pushes for user-visible notifications background pushes (content-available: 1, apns-push-type: background, apns-priority: 5) for background data delivery When the iPhone app receives the push, it relays data to the watch using WatchConnectivity. On the iPhone/watch side: we use sendMessage when reachable / foreground-like communication is possible we use transferUserInfo as the background / unreachable fallback The devices are paired and connected, and the apps are not force-quit. In practice, the behavior is not stable enough for this requirement: some background deliveries are delayed some relays to the watch are not timely the end-to-end behavior is not reliable enough for independent event delivery with near-real-time expectations My understanding is that: APNs background pushes are not guaranteed and may be throttled WatchConnectivity background delivery is opportunistic immediate WC messaging depends on reachability / active state So the main question is not how to debug a single implementation issue, but whether our expectation is valid at all on Apple platforms. Questions: Is this architecture fundamentally unsuitable if the requirement is lossless, near-real-time event delivery from server -> iPhone -> watch, with a target of roughly within 5 seconds? Even if the implementation is correct, should we expect iPhone background push + WatchConnectivity relay to remain inherently non-deterministic for this kind of requirement, especially in scenarios where events may occur approximately once per minute? If notification mirroring is used only for user awareness, but the watch app still needs reliable background state/data delivery before the user opens it, is there any Apple-supported architecture for that? Would direct delivery to the watch app be the only realistic direction, or is this level of reliability/latency simply not a supported expectation for general-purpose apps? We understand that background execution and delivery are managed opportunistically by the system. What I want to confirm is whether this requirement itself is outside the practical/supported envelope of APNs background push + WatchConnectivity relay.

Hello guys, We have updated our app icon, and it is correctly reflected in our app build and assets. However, the push notification icon is still displaying the old version for some users. ✅ We have verified that: All icon assets in Assets.xcassets match the new icon. The app icon has been updated in Info.plist. The app has been resubmitted and approved on the App Store. ❌ However, some users still see the old notification icon, even after reinstalling the app. Restarting the device does not always resolve the issue. Could you provide insights into how iOS caches notification icons and how we can force a refresh for all users?

I am working on a large-scale e-commerce application and we are trying to solve a specific issue regarding push notifications and user experience. We have a use case where we need to send a standard push notification to the user, but under certain local conditions on the device, we want to intercept that notification via a Notification Service Extension and suppress/drop it so it does not alert the user. We understand that the com.apple.developer.usernotifications.filtering entitlement allows a Notification Service Extension to drop notifications. However, looking at the entitlement request form, the categories seem strictly limited to: End-to-end encrypted messaging Earthquake warnings Education/learning platforms Enterprise healthcare apps My questions for the community and Apple staff: Is it possible for an e-commerce or retail app to be approved for this entitlement if we have a highly specific, valid use case that improves user experience. If this entitlement is strictly off-limits for our domain, what is the Apple-recommended architecture to achieve this? Thank you in advance for any insights or guidance!

Good day) Colleagues, please tell me how can I change the notification on the locked screen "pass changed" in PKPASS when changing several fields? Thank you very much for your answer

token：eb3b63ab94b136f6d25a86d48bb4b7ff20377e393f137cb4f43b17560112bf51 msgId：67d4c88d-61b1-4f51-df0b-2efa022fd672 机型：iPhone7 系统：iOS 15.8.3 问题描述：后端服务器调用苹果提供的pushKit推送API且已成功返回上述msgId，客户端App也已经实现对应的CallKit方法reportNewIncomingCall，但没有收到对应的推送，这是什么原因呢？

Since upgrading to Xcode 26 beta 4 and using the iOS 26 simulator for testing our app, we've stopped being able to receive device tokens for the simulator from the development APNS environment. The APNS environment is able to return meta device information (e.g. model, type, manufacturer) but there are no device tokens present. When running the same app using the iOS 18.5 simulator, we are able to register the device with the same APNS environment and receive a valid device token.

In my Notification Service Extension I'm doing two things in parallel inside didReceive(_:withContentHandler:): Downloading and attaching a rich media image (the standard content modification work) Firing a separate analytics POST request (fire-and-forget I don't wait for its response) Once the image is ready, I call contentHandler(modifiedContent). The notification renders correctly. What I've observed (via Proxyman) is that the analytics POST request completes successfully after contentHandler has already been called. My question: Why does this network request complete? Is it because: (a) The extension process is guaranteed to stay alive for the full 30-second budget, even after contentHandler is called so my URLSession task continues executing during the remaining time? (b) The extension process loses CPU time after contentHandler but remains in memory for process reuse and the request completes at the socket/OS level without my completion handler ever firing? (c) Something else entirely? I'd like to understand the documented behaviour so I can decide whether it's safe to rely on fire-and-forget network requests completing after contentHandler, or whether I need to ensure the request finishes before calling contentHandler.

Issue: Push notifications are not being received for some users. What could be the possible causes? Push notifications are being sent from our own server, and we are receiving success responses from APNS. Users have confirmed that notifications are enabled on their devices, and they report no network issues.

Hello, I am currently developing an MDM solution, including both the sever-side(.NET) and the client app. I have recently been granted the "MDM CSR" signing permission in the Certificates, Identifier & Profiles of my developer account. I am following the official Apple documentation, "Setting up Push Notifications for your MDM Customers," to generate the required MDM Push Certificate. However, I keep encountering the "Invalid Certificate Signing Request" error when uploading the encoded .plist file to the Apple Push Certificates Portal(identity.apple.com/pushcert). The steps I have taken so far: Generated .csr file via Keychain Access Used the MDM SCR certificate to sign the request. Created a .plist file for th final upload containing : Customer CSR: Base64 encoded Signature : Signed using the SHA256withRSA algorithm and Base64 encoded. Certificate Chain : Including my MDM Vendor Signing Certificate, the Apple WWDR intermediate certificate, and the Apple Root CA. Issues/Questions: Is there a specific requirement for the order of the certificates in the chain? Are there common pitfalls regarding the .plist structure or the encoding of the signature that might cause the "Invalid CSR" error? Is there a tool or a specific validation step I can use to verify the integrity of the generated .plist before uploading? I have double-checked the encoding and the signing process, but the portal continues to reject the request. Any insights or guidance from community would be greatly appreciated. Thank you in advance for your help!

The following issue has occurred: Push notifications are not being received on certain devices. What could be the possible causes? Push notifications are being sent from our own server, and we are receiving normal responses from APNs. Users have confirmed that notifications are enabled on their devices, and they report no network issues. This problem is occurring for multiple users.

Hello, I'm from Microsoft team maintaining push notification api behind Teams platform. We are experiencing strange and short error spikes towards APNS that seem to mostly correlate worldwide. We checked the networking and push request code but could not find what could be causing this. These error spikes are all timeouts or connection resets (by remote host, ie. APNS servers) and seem to come and go randomly: Would it be possible to check this for outages or some other metrics on your side or investigate why would it happen? Since it's worldwide it seems unlikely it's something broken on our side. We are using the standard APNS http2 endpoint with modern support for all RFC features (so everything should work normally). Mind you, our api might be in a unique position because of the volume of notifications (in the billions per day).

Hello, We are experiencing an issue related to push notifications after updating devices to iOS 26.4 Beta. Our system stores push notification tokens on the server by associating the device token with the device’s IDFV in the app. After updating a device to iOS 26.4 Beta, we observed that the device token from a previously uninstalled version of the app remains valid for more than a week. As a result, two push notifications are delivered to the same device. The situation is as follows: The user installs the app and a device token is generated. The user uninstalls the app. Later, the user installs the app again and a new device token is generated. However, the previous device token does not become invalid, even after more than a week. Because IDFV changes when the app is reinstalled, our server cannot determine that the device belongs to the same user. Therefore, we cannot overwrite the old token with the new one on the server side. Could you please advise: Is this behavior expected in iOS 26.4 Beta? How long does it normally take for a device token to become invalid after an app is uninstalled? What is the recommended approach to prevent duplicate push notifications in this situation? Any guidance would be greatly appreciated. Best regards